Hallo zusammen, herzlich willkommen zu meinem Vortrag über Cancu.

Continuous Integration the Easy Way heißt der Vortrag.

Mein Name ist Frank Schreiner, ich arbeite bei SUSE im OBS Backend Team als Perl Developer.

Meine Frage, wer hat letztes Jahr meinen Vortrag über den OBS gesehen?

Okay, hat jemand schon mal OBS benutzt? Cool.

Worum es jetzt heute gehen wird, ich werde also erst einmal eine Übersicht zeigen, wie mein Workflow in der Arbeit aussieht.

Dann geht es ein bisschen um die Motivation und Gold hinter CanCu.

Eine Overview über die Modes, die Basiskonzepte und die Architektur.

Also so ungefähr sieht das bei mir aus.

Als Entwickler pushe ich auf Git, in meinem Fall GitHub.

Der Source Code wird dann vom OBS gezogen und der baut mir dann die Pakete.

Aus diesen Paketen baut dann Kiwi-Images für VMs in dem speziellen Fall.

Und CanCu zieht dann diese Images und werden dann weiter verarbeitet.

Also entweder werden Tests gemacht oder ich benutze es dann auch auf meinem Laptop zum Development.

Dann gehen wir mal weiter. Die Goals, die ich eigentlich erreichen wollte, dass es leichter wird mit den Images vom OBS zu bauen bzw. die zu verwenden in der täglichen Arbeit.

Dann sollte das Ganze leicht zu konfigurieren sein.

Also das ist ein Jaml-File, in das man seine ganzen Instruktionen dann reinschreibt.

Es sollte simple Jobs in komplexen Setups ermöglichen.

Es sollte eine Zusammenarbeit unter Kollegen ermöglichen.

Und es sollte skriptbar sein, sprich ich habe eine REST-API und dazu gibt es einen Remote-Client, wo man die wichtigsten Kommandos oder eigentlich alle Kommandos, die man so im Web-Frontend ausführen kann, dann auch auf der Command Line praktisch ausführen kann.

Jetzt gleich mal ein Spoiler, es geht hier also nicht um Container, es geht wirklich um VM-Images.

Hier sieht man mal so einen Einstieg, wie man sich so eine Maschine erstellen kann. Also man kann mit Canco LSI und dahinter Minus N und einem Suchbegriff sich mal Images auflisten lassen, die schon vorgebaut sind praktisch.

Wir haben nicht nur Open-SUSE-Images, sondern auch Ubuntu, Fedora und CentOS.

Danach macht man Canco Init und der Canco Init erzeugt einem dann so eine Template-Konfigurationsdatei, mit der man dann direkt loslegen kann.

Und mit dem Canco Up startet man dann praktisch die Maschine und am Ende des Vorgangs hat man dann eine laufende Maschine, auf die man dann per SSH zum Beispiel connecten kann.

Ja, ich habe das unterbringen müssen. Nur ein Jammerl-Pfeil, wie immer, sieht dann so aus. Man kriegt also da so ein grob Gerüst, es gibt hier Sachen, die habe ich jetzt mal ausgelassen, weil die für unseren Fall jetzt hier nicht wichtig sind.

Am wichtigsten ist eigentlich zum Schluss, hat man hier so eine Sektion, wo man dann die Kommandos automatisch per SSH ausführen kann. Wenn dann alles abgelaufen ist, kann man dann eben über Canco SSH in die Maschine reinkonekten und kann dann debuggen, wenn es Probleme gibt oder kann einfach so entwickeln anfangen.

Im Developer Mode wird auch das aktuelle Verzeichnis mit der VM geschert.

So, jetzt mal eine Overview, was ich heute durchsprechen möchte. Das sind einmal die Modes, da haben wir zwei. Einmal den Developer Mode, das ist gedacht, um auf der lokalen Maschine zu laufen oder in den Server Mode.

Dann wird es um die Basic Concepts gehen, also was sind Jobs, was sind Tasks, was sind eigentlich Händler, was sind diese Utility-Klassen und dann gibt es noch die Notifier.

Und danach werde ich eine Basisübersicht von der Architektur im Server-Bereich zeigen.

Also der Developer Mode ist designt, eben um auf der Workstation oder dem Laptop vom Entwickler zu laufen. Das ist ähnlich wie bei Vagrant oder auch Docker.

Die Jobs werden in dem Fall über das Canco App manuell getriggert. Ich habe auch einen Offline-Mode eingebaut, weil ich viel auf Reisen bin und dann eigentlich nicht eine stabile Internet-Connection habe.

Deswegen wollte ich, dass meine Images lokal gecashed werden und dann über den Offline-Mode trotzdem meine Maschinen starten kann.

Und wie gesagt, das Working Directory wird eben mit der VM dann geshared. Man kann also in der VM auf die Sachen von außen auch zugreifen.

Dann im Server-Mode haben wir eben, dass wir unter, also wir können horizontal skalieren. Das funktioniert über eine RabbitMQ, die eine Jobverteilung macht.

Da müssen die Server, also müssen halt die Worker-Server angemeldet sein am Haupt-Server, am Master-Server und dann können die Jobs eben über mehrere Maschinen verteilt werden.

Jobs können getriggert werden über ein Event, zum Beispiel über ein RabbitMQ-Event oder über das Webfrontend oder eben über die CLI oder REST API, wie auch immer.

Es gibt einen Scheduler, der praktisch die Jobs dann periodisch anstößt, zum Beispiel wenn ich eine Maschine habe oder ein Projekt, das nicht so oft Commits bekommt, wo nicht so oft Pakete gebaut werden oder Images,

dann kann ich die praktisch einmal wöchentlich zum Beispiel nochmal neu bauen lassen.

Ein Anwendungsfall davon ist zum Beispiel, dass man sich eine Virtual-Maschine hochschießen kann, auf der man dann eben entwickeln kann.

Es gibt dann auch ein Port-Vorwärtsding, also man kann sich auch von Remote auf den Maschinen direkt per SSH einlocken oder zum Beispiel HTTPS weiterleiten lassen,

was es sehr praktisch macht, dann mit den Kollegen praktisch gemeinsam auf einer VM, zum Beispiel im Squeen oder so zu arbeiten.

Hier haben wir mal eine Aufstellung oder eine Übersicht, wie so ein Canco-File dann eigentlich aussieht oder wie die Idee dahinter ist.

Also das ist ein Job, das ist die übergeordnete Einheit praktisch.

Wir haben dann verschiedene Tasks, die man aneinander stacken kann, beliebig viele, beliebig oft, beliebig lang und in der Reihenfolge, in der man es halt einfach braucht.

Zum Beispiel einer dieser Tasks kann dann, also ein Task führt immer einen Handler aus.

Ein Handler ist im Endeffekt nur ein Modul, das über drei Routinen oder drei Methoden verfügen sollte, prepare, execute und finalize.

Dahinten sieht man dann auch die Utils, da komme ich dann nachher nochmal drauf, was man mit den Utils, wofür die da sind.

Es gibt dann sogenannte Getter- und Setter-Methoden, die in diesem Job-Kontext Variablen schreiben können und wieder lesen können,